Codecov Report

Merging #2893 (b45d71a) into main (0f3e4de) will decrease coverage by 0.92%.
The diff coverage is 80.32%.

@@            Coverage Diff             @@
##             main    #2893      +/-   ##
==========================================
- Coverage   93.73%   92.81%   -0.93%     
==========================================
  Files         187      184       -3     
  Lines        6145     6066      -79     
  Branches     1308     1296      -12     
==========================================
- Hits         5760     5630     -130     
- Misses        385      436      +51     

@pichlermarc hi, could you please provide an update on this? I wonder what's the ETA. Thx

@pichlermarc hi, could you please provide an update on this? I wonder what's the ETA. Thx

I'm not in the office this week, so I handed this PR over to @dyladan while I'm away. It is pretty much done though, but when I left some checks were failing.

There is still some minor cleanup but i'll mark it as ready for review so we can get some 👀 on it

Hi team,
Are we good here to move forward?

Currently the metrics exporters depend on the trace exporters, which causes unwanted dependencies to Trace packages via the Metrics exporters

What is the plan for the future for these exporters? do we plan to keep them separated or merge them into a single exporter per-protocol that can export all stable signals (trace, metrics, and logs in the future)?

I don't see any good reason to separate them once metrics is stable, in which case we will probably need to merge these new packages back soon, right?
If we do want them separated in the future as well, should we also split the otlp-transformer package into per-signal packages?

As far as I know the exporters were split by signal in order to keep bundle size down. This was originally done by @obecny. Personally I think the developer experience is better to have a single exporter for all signals, but I'm not sure how much this affects the bundle size. Maybe @MSNev has some idea?

Currently the metrics exporters depend on the trace exporters, which causes unwanted dependencies to Trace packages via the Metrics exporters

What is the plan for the future for these exporters? do we plan to keep them separated or merge them into a single exporter per-protocol that can export all stable signals (trace, metrics, and logs in the future)?

I think this depends on if we want to support signals being used independently (see @dyladan's answer on bundle size). Regardless of that, I think keeping these new packages until the Logs SDK is stable is necessary if we want to keep experimental code in experimental/.

I don't see any good reason to separate them once metrics is stable, in which case we will probably need to merge these new packages back soon, right? If we do want them separated in the future as well, should we also split the otlp-transformer package into per-signal packages?

I think we would have to split otlp-transformer into three (utils, traces, metrics or four, with logs) as well, yes. otlp-transformer depends on sdk-metrics-base and sdk-trace-base right now.

When it was used for example in aws lambda (if I remember correctly) you don't want to have many MB as there is already a limit for your function. The same applies for browser you don't want to load many unneeded MB or kB of code. So hence the decision to split them so the user can include only what is necessary

Even if we merged trace/metrics OTLP exporters into one stable package, I think in the case of reducing bundle size in certain environments, people could still use tools to tree-shaking unused code components.